最近剛好有一名老將，要展開職涯的下一個規劃
(我真的很擔心我同事發現我有進行鐵人賽，然後或得到太多還沒公開的資訊！？)
又要開始一輪面試，所以相對應就有些感觸，來跟大家分享一下

因為在職缺上有特別強調團隊運行敏捷文化與需要的一些特質
所以在面試時，也會特別詢問受試者有沒有聽過／運行過敏捷式開發的經驗
也會著重介紹我們團隊運行的敏捷與方式
有意思的是
反而是曾經待過敏捷團隊的人，會比較訝異關於我們運行方式

通常彼此遇到的歧異點為：
1.工程師只需要參加 Standing
2.有聽過 Review 會議，但需要參加 Review 會議的只有主管
3.沒有聽過 Retro 會議，然後很驚訝我們 Retro 會議可能要半天
4.事情是 PM 分派下來的，不太會有自己決定要做什麼的機會
結果到最後反而是在考驗我，讓我來介紹我們團隊的玩法。

*大部分聽完我們團隊的互動模式後，進而追問一些細節，展現濃厚的興趣(自豪！)
或許這就是對於我們的一種肯定吧？！
至於後續有沒有跟人資談妥薪資就...

回過頭來看團隊是否健康這件事

除了透過觀察受試者聽到團隊運行模式的反應以外(前提是要誠實的描述喔)
我個人認為有兩點可以作為觀察

1.Scrum 的五大會議中，有一個會議影響深遠

有哪五大呢？哪一個最重要呢？
我們直接上結論

1.Sprint Planning
2.Sprint Standing
3.Product Backlog Refinement
4.Sprint Review
5.Sprint Retro

Retro 會議最為重要

在所有會議都可以請假看錄影回放
但 Retro 不行，會希望成員到場

因為有了 Retro 會議，讓團隊除了專案以外，本身也能自我迭代

牽強一點的說，能夠自我反省的團隊，也應該不會遇到什麼跨不過的坎。
當然這裡講的 Retro 會議不能只是吃吃喝喝的混掉一個下午
而是要有討論到團隊的痛點，並且承諾於接下來要勇於面對它。

2.Sprint 的內容做不做得完

做不完的 Sprint 是沒有意義的

我總是時時刻刻地在任何報告裡提到這句話
因為不論是來自同公司其他部門的朋友或是一些很強的朋友們(我都可以確認他們能力上是無庸置疑的)
都常常跟我抱怨東西做不完，
甚至是有一個很強的朋友在新公司第一次跑敏捷，跟了兩個 Sprint 後，就壓力大到胃潰瘍

事情做不完通常也不外乎只有兩個問題
1.個人能力有問題
2.安排事情的那個人有問題

切記
Sprint 是衝刺，不是馬拉松

如果日常大家都被繁重的工作壓得喘不過氣來的話，
何來有空思考如何進步呢？

今天跟大家分享了我心目中的
團隊敏捷，至於專案敏捷和個人敏捷 礙於篇幅 留給明天來分享吧

參考資料：
無